The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section. Similarly, unless otherwise indicated, it should not be assumed that a problem has been recognized by the prior art merely because the problem is discussed in this section.
For convenience of expression, various entities that represent sets of instructions (e.g. functions, queries) are described as performing actions, when in fact, a computer, process, database server, or other executing entity performs those actions in response to executing or interpreting the set of instructions. For example, a function may be described as determining that a condition exists or a query may be described as accessing information. These are just convenient ways of expressing that a computer, process, database server or other executing entity is determining that a condition exists in response to executing a function or is accessing data in response to executing or computing a query.
A database server, also referred to as a database management system (DBMS), retrieves and manipulates data in response to receiving a database statement. Typically the database statement conforms to a database language (e.g., a query language), such as Structured Query Language (SQL). A database statement can specify a query operation, a data manipulation operation, or a combination thereof. A database statement that specifies a query operation is referred to herein as a query. The present invention is not limited to database statements that specify a particular type of operation. Some other examples of database statements other examples of database statements are updates and deletes. However, for the purpose of explanation, embodiments of the present invention are illustrated using queries.
A database language, as the term is used herein, is a declarative language. A declarative language provides constructs for describing results but not steps performed to generate the results. The data base language SQL, for example, provides constructs for specify what data field to provide (e.g., the SELECT and FROM clauses specify the columns in the results), and the WHERE clause to specify criteria (e.g. a predicate) that the data should satisfy. The database statement is submitted to a database server, which has components that figure out how to compute the results, and the results are generated accordingly. See Kaufman et al., Beginning SQL Programming, Wrox Press Inc (March 2001), the contents of which are also incorporated herein by reference.
It is often useful to convey information about database statements to a database server other than information that only describes the results. Such information is referred to herein as database statement control information, or just control information. For example, it is useful to provide instructions to a query optimizer about how to generate an execution plan for a database statement. An approach for conveying such information is to use an “optimizer hint”. An optimizer hint is an instruction embedded in a database statement that is interpreted by a query optimizer to assist it in determining an execution plan for executing a database statement. An optimizer hint may specify an index to scan when computing the results of a query. Optimizer hints and execution plan are described in further detail in Daniel ManHung Wong, et al., U.S. patent application Ser. No. 10/431,071, entitled “DYNAMIC GENERATION OF OPTIMIZER HINTS”, the contents of which are incorporated herein by reference, and in Oracle 9i Database Performance Guide and Reference, Release 1 (9.0.1), Part Number A87503-02, the contents of which are also incorporated herein by reference.
A drawback of optimizer hints is that optimizer hints may be used for conveying information only about generating an execution plan. The information is only conveyed to the query optimizer, the component of database server responsible for generating execution plans. Often, it is useful to convey other types of control information to other components of a database server, such as security information to access control components of a database server, priority information to scheduling components of the database server, or information to non-native user-supplied components of database server (e.g., user-supplied functions).
One such mechanism that allows such information to be conveyed is the user context, which includes user context information. User context information is data which is maintained by a database server and that is associated with a database session. A database session is the establishment of a particular connection between a client and a database server through which a series of calls to the database server may be made. The period of time the client remains connected in the database session is referred to as the session window. Thus, the session window ends when the session is terminated.
A user context includes various attributes, such as the user id identifying the user associated with the database session and application id identifying an application associated with the database session. The user context information is accessed by the database server and its various components. For example, the user context information may be accessed by an access control component to determine access control information. Some attributes may be set only by a database server, by a user (via an API call), or by a user subject to certain security restrictions imposed by the database server. A user context is useful for storing and conveying information to various database server components.
A drawback to using a user context is that the information is only stored in memory allocated to database sessions, which is referred to herein as session space. The user context is stored in the session space of a database session, and therefore does not persist beyond the session window of the database session.
For example, within a database session, a user submits a query that is to be executed by a background process or background server at a later scheduled time. Subsequent to the end of the session window, the background process executes the query. Because the user context is no longer stored, it cannot be used to convey information to the background process when it computes the query.
Thus, there is a need for a mechanism that conveys control information other than to a query optimizer outside a database session.